home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950726-19950929 / 000119_news@columbia.edu_Wed Aug 9 09:42:37 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA16420
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Wed, 9 Aug 1995 20:53:36 -0400
  3. Received: by apakabar.cc.columbia.edu id AA01163
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 9 Aug 1995 20:53:34 -0400
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.provo.novell.com!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: MSKermit over IP connection
  9. Message-Id: <1995Aug9.154237.58499@cc.usu.edu>
  10. Date: 9 Aug 95 15:42:37 MDT
  11. References: <4073r0$ijs@linda.teleport.com> <1995Aug8.082408.58352@cc.usu.edu> <409uom$apq@kelly.teleport.com>
  12. Organization: Utah State University
  13. Lines: 84
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <409uom$apq@kelly.teleport.com>, sysone@teleport.com (FIGHT THE POWER) writes:
  17. >     I'll _try_ to recast this coherently... :-)
  18. > 
  19. >     Joe D. wrote:
  20. > 
  21. > #    I'm not sure I follow all the details above, but let me take a
  22. > #stab at matters.
  23. > #    SLIP is a point to point transport mechanism with only two stations
  24. > #on the wire: this end and "the other end". There is no ARP-ing involved
  25. > #since ARP is a way of finding one of many stations on the same broadcast
  26. > #medium (and a serial link isn't a broadcast medium). CSLIPPER is a SLIP
  27. > #Packet Driver.
  28. > 
  29. >     Right... I'm thinking of the connection as running
  30. > something like this:
  31. > 
  32. >     [My DOS app] -> [SLIP or PPP client] -> [Serial card] ->
  33. > [My modem] -> [Telephone network] -> [Server's modem] ->
  34. > [Server's port] -> [SLIP or PPP server] -> [Server's LAN] ->
  35. > [LAN's TCP/IP gateway] -> Internet stuff...
  36. > 
  37. > #    Given a point to point architecture "the other end" is responsible
  38. > #for transporting packets to far away places, and hence it is both a host
  39. > #and the gateway. Figuring out what to do with packets not addressed to it
  40. > #is a problem that other end has to deal with. I have no idea of how you
  41. > #have the Cisco boxes configured. In any case, SLIP has no notion of routing, 
  42. > 
  43. >     I don't know about the Ciscos' configurations either,
  44. > although I can get some information from the server prompt using
  45. > the 'show' command with various extensions. I have asked the
  46. > support office here re the manuals... which they couldn't locate!
  47. > 
  48. > #gateway, or ARP. Any routing which does occur is a pleasant side effect
  49. > #of "the other end."
  50. > #
  51. >     I'm thinking that the server, attempting to link me to
  52. > the Net, can't resolve the gateway's IP address into a valid
  53. > Ethernet address, and sends some message to this effect back to
  54. > the client. Since the client (DOS Kermit in this case) is
  55. > attached to the server via SLIP/PPP, the message is passed over
  56. > the link layer back to my SLIP/PPP driver, which complains to
  57. > Kermit; the link layer has nothing to do with all this beyond
  58. > hauling datagrams back and forth.
  59. > 
  60. >     All this is based on my exceedingly limited knowledge of
  61. > networking of course. I'm probably out to lunch on some of it.
  62. > 
  63. > #    EtherPPP is the MERIT item, I presume. Honestly, I have never been
  64. > #able to get that program to work in any way; it always hangs my machine as
  65. > #it starts up. Thus I have nothing useful to suggest for it.
  66. > #
  67. >     Yup, configuring EtherPPP is a unique experience. It
  68. > works great now that I've figured out the settings my machine
  69. > likes. But that doesn't mean I've found a configuration which
  70. > would work everywhere. To return to the topic, the ARP problem
  71. > appears to occur independent of the driver (I have tried two
  72. > EtherPPP releases as well as the {,C}Slipper drivers). With the
  73. > earlier Kermit no problem. With the recent Kermit, the ARP error
  74. > is returned.
  75. > 
  76. > #    Adding to my confusion on your report is "name resolution doesn't
  77. > #seem to be a problem." If the nameserver is far away, in the SLIP sense,
  78. > #then that is no different than trying to reach another machine far away. 
  79. > #
  80. >     Right. An inadvertent red herring on my part...
  81. > 
  82. >     I don't know if what I have added is helpful in
  83. > diagnosing the problem. I would be more than happy to mail in
  84. > session transcripts, config files &c. if this would help. I
  85. > suppose I've used enough bandwidth on this question at any rate.
  86. > 
  87. >     Thanks...
  88. -------------
  89.     I fired up CSLIPPER with no command line arguments so it behaved
  90. as a straight SLIP Packet Driver. I ran MS-DOS Kermit over it to our modem
  91. pool (Telebit Netblazers) and used both domain name servers and far away
  92. machine addresses, all with no difficulty. I set the MSK TCP/IP IP address
  93. from the text line the modem pool gave me upon starting SLIP there.
  94.     I notice that CSLIPPER has an ARP/IP Ethernet faker option. Without 
  95. knowing in detail what it does I would recommend not activating that faker 
  96. with Kermit.
  97.     From this I am tempted to conclude that the IP environment outside
  98. of Kermit is causing the difficulties you note.
  99.     Joe D.